Client-side aggregation of nested resource dependencies

ABSTRACT

A computer-implemented method, system, and/or computer program product retrieves a nested resource. A client computer identifies software modules that are required by a primary software module. The dependent and primary software modules are consolidated at a client computer into an aggregated software module, which is a nested resource. A request for the aggregated software module is transmitted to a module server from a client-side module loader, which is incapable of identifying a name of received software modules from the module server. The client-side module loader in the client computer then receives the requested aggregated software module without any identification.

BACKGROUND

The present disclosure relates to the field of computers, andspecifically to the use of computers when used for developingmodule-based software. Still more particularly, the present disclosurerelates to requesting nested software modules.

A software framework (“framework”) provides an organization forsoftware. This organization includes generic functionality as well asuser-modifiable functionality. The software framework includescompilers, libraries of software code, application programminginterfaces (APIs), and tools sets that allow a user to combine differentcomponents into a program solution.

SUMMARY

A computer-implemented method, system, and/or computer program productretrieves a nested resource. A client computer identifies softwaremodules that are required by a primary software module. The dependentand primary software modules are consolidated at a client computer intoan aggregated software module, which is an exemplary nested resource. Arequest for the aggregated software module is transmitted to a moduleserver from a client-side module loader, which is incapable ofidentifying a name of received software modules from the module server.The client-side module loader in the client computer then receives therequested aggregated software module without any identification.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 depicts an exemplary system and network which may be used toimplement the present invention;

FIG. 2 illustrates an exemplary system for requesting and receivingaggregate modules as described herein; and

FIG. 3 is a high level flow chart of one or more exemplary steps takenby a processor or other computer hardware to retrieve nested softwaremodules in accordance with one or more embodiments of the presentinvention.

DETAILED DESCRIPTION

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including, but not limited to, wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

As noted herein, a complex stream computer utilizes software andhardware components that interact with one another, such that adownstream component is reliant on an output from an upstream componentin the complex stream computer. Thus, such systems are notoriouslydifficult to debug. That is, if the output of the entire stream computerfails, (i.e., if the output is an error code, is nonsense, is outside ofan acceptable range, etc.), the upstream cause within the complex streamcomputer is difficult to identify by simply backtracking. The presentinvention presents a novel approach to identifying root causes in suchcascade processes.

With reference now to the figures, and in particular to FIG. 1, there isdepicted a block diagram of an exemplary system and network that may beutilized by and/or in the implementation of the present invention. Notethat some or all of the exemplary architecture, including both depictedhardware and software, shown for and within computer 102 may be utilizedby software deploying server 150 and/or software module server 152.

Exemplary computer 102 includes a processor 104 that is coupled to asystem bus 106. Processor 104 may utilize one or more processors, eachof which has one or more processor cores. A video adapter 108, whichdrives/supports a display 110, is also coupled to system bus 106. Systembus 106 is coupled via a bus bridge 112 to an input/output (I/O) bus114. An I/O interface 116 is coupled to I/O bus 114. I/O interface 116affords communication with various I/O devices, including a keyboard118, a mouse 120, a media tray 122 (which may include storage devicessuch as CD-ROM drives, multi-media interfaces, etc.), a printer 124, andexternal USB port(s) 126. While the format of the ports connected to I/Ointerface 116 may be any known to those skilled in the art of computerarchitecture, in one embodiment some or all of these ports are universalserial bus (USB) ports.

As depicted, computer 102 is able to communicate with a softwaredeploying server 150 using a network interface 130. Network interface130 is a hardware network interface, such as a network interface card(NIC), etc. Network 128 may be an external network such as the Internet,or an internal network such as an Ethernet or a virtual private network(VPN).

A hard drive interface 132 is also coupled to system bus 106. Hard driveinterface 132 interfaces with a hard drive 134. In one embodiment, harddrive 134 populates a system memory 136, which is also coupled to systembus 106. System memory is defined as a lowest level of volatile memoryin computer 102. This volatile memory includes additional higher levelsof volatile memory (not shown), including, but not limited to, cachememory, registers and buffers. Data that populates system memory 136includes computer 102's operating system (OS) 138 and applicationprograms 144.

OS 138 includes a shell 140, for providing transparent user access toresources such as application programs 144. Generally, shell 140 is aprogram that provides an interpreter and an interface between the userand the operating system. More specifically, shell 140 executes commandsthat are entered into a command line user interface or from a file.Thus, shell 140, also called a command processor, is generally thehighest level of the operating system software hierarchy and serves as acommand interpreter. The shell provides a system prompt, interpretscommands entered by keyboard, mouse, or other user input media, andsends the interpreted command(s) to the appropriate lower levels of theoperating system (e.g., a kernel 142) for processing. Note that whileshell 140 is a text-based, line-oriented user interface, the presentinvention will equally well support other user interface modes, such asgraphical, voice, gestural, etc.

As depicted, OS 138 also includes kernel 142, which includes lowerlevels of functionality for OS 138, including providing essentialservices required by other parts of OS 138 and application programs 144,including memory management, process and task management, diskmanagement, and mouse and keyboard management.

Application programs 144 include a renderer, shown in exemplary manneras a browser 146. Browser 146 includes program modules and instructionsenabling a world wide web (WWW) client (i.e., computer 102) to send andreceive network messages to the Internet using hypertext transferprotocol (HTTP) messaging, thus enabling communication with softwaredeploying server 150 and other computer systems such as software moduleserver 152.

Application programs 144 in computer 102's system memory (as well assoftware deploying server 150's system memory) also include a NestedResource Dependency Determination and Aggregation Logic (NRDDAL) 148.NRDDAL 148 includes code for implementing the processes described below,including those described in FIGS. 2-3. In one embodiment, computer 102is able to download NRDDAL 148 from software deploying server 150,including in an on-demand basis, wherein the code in NRDDAL 148 is notdownloaded until needed for execution. Note further that, in oneembodiment of the present invention, software deploying server 150performs all of the functions associated with the present invention(including execution of NRDDAL 148), thus freeing computer 102 fromhaving to use its own internal computing resources to execute NRDDAL148.

Note that the hardware elements depicted in computer 102 are notintended to be exhaustive, but rather are representative to highlightessential components required by the present invention. For instance,computer 102 may include alternate memory storage devices such asmagnetic cassettes, digital versatile disks (DVDs), Bernoullicartridges, and the like. These and other variations are intended to bewithin the spirit and scope of the present invention.

Frameworks (“software frameworks”) for javascript applications typicallyimplement functionality in a number of separate javascript source filesthat need to be loaded on the client by a client-side module loader,such as a web browser. The frameworks implement a loader component thatthe application code loads into the application, and then the loaderrequests the modules of the framework that are needed in order toimplement the functionality that is required by the application.However, the client-side module loader is unable to identify whatmodules are returned. That is, under the Asynchronous Module Definition(AMD) specification, the client-side module loader simply assumes thatwhatever module it requested will be returned, without adding any othermodules. For example, assume that the client-side module loader requestsa software module named “alpha”. However, when a module server receivesthe request, it determines that the software module “alpha” also needsdependent software modules “dep1” and “dep2” in order to function, andthus returns the dependent software modules “dep1” and “dep2” to theclient-side module loader. However, the client-side module loader isonly expecting the software module “alpha”, and thus there is often asystem malfunction when software modules “dep1” and “dep2” are alsoreturned.

With reference now to FIG. 2, an exemplary system 200 for requesting andreceiving aggregate software modules as described herein is presented. Aclient computer 202 (e.g., computer 102 depicted in FIG. 1) includes aclient-side software module loader (“loader 204”). Associated withloader 204 is a nested resource aggregation logic 206, which may be partof the NRDDAL 148 depicted in FIG. 1. In response to the client computerrequesting a primary software module (e.g., “alpha”), the loader 204will send an inquiry to the nested resource aggregation logic 206 todetermine if there are any dependent software modules that “alpha” willrequire in order to execute properly. If there are any such dependentsoftware modules, then the nested resource aggregation logic 206, alongwith the loader 204, will combine (consolidate) the primary softwaremodule (“alpha”) with the dependent software modules (“dep1” and “dep2”)to generate an aggregated software module, which is a nested resource ofsoftware modules. A request for this aggregated software module is sent,via an aggregated software module request 208, to a software modulesdatabase 210 within a software module server 212 (e.g., software moduleserver 152 shown in FIG. 1). The software module server 212 then returnsthe requested aggregated software module in an aggregated softwaremodule response 214.

Note that in one embodiment, the present invention utilizes AMD or asimilarly well-defined module definition scheme. A brief description ofAMD follows:

The AMD Application Program Interface (API) specifies a mechanism fordefining modules such that the module and its dependencies can beasynchronously loaded. There are two main functions specified by theAPI: require( ) and define( ) The define function defines a module. Eachmodule has a define( ) function, which is usually the outer element ofthe entire module. The main purpose (other than encapsulating the moduleimplementation) of the define( ) function is to specify the module'sdependencies.

Consider now the following pseudo code:

define(“alpha”, [“dep1”, “dep2”], function(dep1, dep2) { return {dep1Something: function(arg) { return dep1(arg); }, dep2Something:function(arg) { return dep2(arg); } }; });

This pseudo code defines a module named “alpha”. The module (i.e.,software module) depends on two other modules, “dep1” and “dep2”. If“alpha” is needed in an application, then the application will call thefunction “require( )”, thus specifying “alpha” in the list of modulesthat it needs. When the AMD loader has loaded “alpha” and itsdependencies, then “alpha”'s define function callback will be called bythe loader and the value returned will be the value of “alpha”. Afterall of the required modules have been loaded and defined, then therequire callback function is called:

require([“alpha”], function(“alpha”) {alpha.dep1.dep2.Something(″hello″); } ) ;

In the preceding example, when require( ) is called, the loader willload module “alpha” (in file alpha.js). After “alpha” has been loaded,the loader will see that “alpha” requires modules “dep1” and “dep2”. Theloader will send out requests for these two modules, and once they areloaded and all dependencies have been resolved, then the loader callsthe callback function that was specified as the second function argumentin the call to require.

One embodiment of the present invention is implemented in an AMD moduleaggregation service. The service utilizes an AMD loader extension thatallows a custom loader module to aggregate requests for multiplemodules, such as the two modules that are listed as alpha'sdependencies, in a single request to the aggregation service. The twomodules will be delivered to the loader in the response.

As part of the aggregation service's initialization, it performs ananalysis of the module dependencies for all of the AMD modules that itserves and produces a dependency graph that allows it to determine thecomplete set of nested dependencies for any module. The service alsoperforms JavaScript minification (white-space and comment removal,shortening of variable names, unnecessary token removal, etc.). TheJavaScript minification requires that the JavaScript modules be parsedinto a tokenized form, known as an Abstract Symbol Table (AST) using aJavaScript compiler.

In one embodiment of the present invention, the AMD aggregation servicetakes advantage of this parsed AST to locate the require functions in anAMD module and expand the list of required modules (the first argumentto the require call) so that the list includes the explicitly specifieddependencies, plus all of that list's nested dependencies. This is doneas part of the JavaScript minification process. So, using the aboveexample, the JavaScript code delivered by the aggregation service forthe module containing the require call would look like the following(not including any JavaScript minification for clarity):

require([“alpha”, “dep1”, “dep2”], function(alpha) {alpha.dep1.dep2.Something(“hello”); });

Note that the module names “dep1” and “dep2” have been added to therequire list by the aggregation service. They did not appear in theoriginal JavaScript source for the module. Now, when this require callis executed on the client, the loader will attempt to load all threemodules, allowing the aggregation service to combine all three modulesin a single request and avoiding the cascaded request resulting fromdependency discovery that a user would get without module listexpansion. If any of the modules have been previously loaded, then theloader simply will not include those modules in the request. This schemeallows the AMD loader on the client to be in charge of maintaining thelist of loaded modules, without having to share this information withthe server or requiring the server to separately maintain the list ofmodules that have already been delivered to the client.

With reference now to FIG. 3, a high level flow chart of one or moreexemplary steps taken by a processor or other computer hardware toretrieve nested software modules in accordance with one or moreembodiments of the present invention is presented.

After initiator block 302, a client computer identifies dependentsoftware modules (e.g., “dep1” and “dep2” described above) that arerequired by a software module (e.g., “alpha” described above), asdescribed in block 304. As described in block 306, the client computer(e.g., through the use of the loader 204 and nested resource aggregationlogic 206 shown in FIG. 2) aggregates the software module with thedependent software modules to generate an aggregated software module,which is a nested resource of software modules. As described in block308, the client-side module loader (e.g., loader 204 in FIG. 2) in theclient computer then transmits a request for the aggregated softwaremodule to a module server. As described herein, the client-side moduleloader, which in one embodiment comports with the AMD specificationdescribed herein, is incapable of identifying a name of receivedsoftware modules from the module server. Thus, the request simplyassumes that whatever is returned from the software module server iswhat the loader requested, with no embellishments, additional modules,removed modules, etc. Since the client aggregates all needed modules,primary and dependent, into the request, then the returned dependentmodules are not unexpected to the loader (i.e., the requested modulesand the returned modules are the same).

In one embodiment, the module server is blocked from returningadditional modules in response to a request for a particular module.That is, the module server (e.g., software module server 212) is limitedto returning only what modules are requested, and is unable to returnany modules (i.e., dependent modules) that are required to execute therequested module. Thus, it is incumbent on the client computer 202 todetermine which modules are “dependent modules” that are required toexecute the “primary module”.

Note that in one embodiment, the module server recognizes the aggregatedsoftware module using AMD specification commands without any plugins.That is, a plugin is defined as an embellishment to the AMDspecification that would provide custom logic for loading a module.Loader plugins can delegate loading of a module to the default loader soit is loaded as other modules though the aggregation service afterpotentially modifying the requested module name or else subsequentlyproviding post-processing of the loaded module data, or it can implementits own loading logic, potentially loading the module from the same or adifferent server, without the use of the aggregation service. However,such a workaround would require 1) the plugin to be installed on boththe client computer as well as the module server, using 2) a programminglanguage that both the client computer and the module server understand(i.e., both systems have been loaded with the same programming languagethat is used by the plugin). The present invention overcomes this issue,since the client computer simply expands the requested modules usingstandard AMD commands, which the module server understands without anyplugins or other embellishments.

As described in block 310, the client-side module loader in the clientcomputer receives the requested aggregated software module. As describedabove, the requested aggregated software module has no identification.However, this does not matter, since the request from the clientcomputer included the requisite dependent software modules. In oneembodiment, these received software modules (both the primary anddependent modules) are then used to populate a software framework.

As described herein, in one embodiment, the client-side module loaderutilizes asynchronous module definition (AMD) specification commands todefine and consolidate the primary software module with the dependentsoftware modules to generate the aggregate software module. As discussedabove, the AMD specification commands include a “define” command toidentify the dependent software modules that are required by thesoftware module, as well as a “require” command to consolidate thesoftware module with the dependent software modules to generate theaggregated software module.

Note that in one embodiment, in response to the client-side moduleloader determining that a particular dependent software module from thedependent software modules has been previously loaded onto the clientcomputer, the client computer removes that particular dependent softwaremodule from the aggregated software module before transmitting therequest for the aggregated software module to the module server. Thus,the client computer only requests the dependent software modules thatare needed by the primary software module.

The process depicted in FIG. 3 ends at terminator block 312.

Note that the present invention allows the client to avoid requestingmodules that it has already received. That is, under one embodiment ofthe present invention, the list of modules that the client sends to theserver is expanded to include only nested dependencies that the clientdoes not already have, instead of including in the response nesteddependencies that the client did not explicitly request.

The present invention further solves the problem of managing moduledependencies in a dynamic module aggregation service that performsdependency expansion to include nested-dependencies. It does this bymodifying the module source that is served so that the list of modulesrequested by the loader on the client includes the expanded, nesteddependencies, rather than a traditional approach of the module serveradding nested, expanded, dependencies that were not explicitly requestedby a client in the server response. This solution avoids the drawbacksof the alternative approaches mentioned above because the server doesnot have to maintain any client state and the client does not have toinform the server of the modules that have already been loaded in eachrequest.

Note that, in various embodiments, the present invention eliminates theneed for the server to maintain client states so that it can rememberwhich modules have already been sent to the client (in order to avoidsending duplicate modules), and makes it possible to support client-sidemodule loader customizations (without any AMD loader plugins). Byexpanding the require list in the delivered code to include the list ofnested dependencies, the application provides the loader with all of themodule names that are needed by the application, including dependentmodule names, so that the loader can request from the server all of therequired modules in a single request, without needing to discover newdependencies as modules are loaded and make additional, cascadingrequests when new dependencies are discovered. At the same time, theloader can decide which modules do not need to be requested, eitherbecause they have already been loaded onto the client, or because theyare not needed for the particular platform/browser or applicationfeature, as determined by a loader. When the request for modules is madeby the client to the server (as a result of the modified requirefunction being called on the client), the server needs only to aggregatethe list of modules requested by the client. There is no need for theserver to compile and include nested dependencies in the responsebecause the nested dependencies that the client needs are specified inthe request.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of various embodiments of the present invention has beenpresented for purposes of illustration and description, but is notintended to be exhaustive or limited to the invention in the formdisclosed. Many modifications and variations will be apparent to thoseof ordinary skill in the art without departing from the scope and spiritof the invention. The embodiment was chosen and described in order tobest explain the principles of the invention and the practicalapplication, and to enable others of ordinary skill in the art tounderstand the invention for various embodiments with variousmodifications as are suited to the particular use contemplated.

Note further that any methods described in the present disclosure may beimplemented through the use of a VHDL (VHSIC Hardware DescriptionLanguage) program and a VHDL chip. VHDL is an exemplary design-entrylanguage for Field Programmable Gate Arrays (FPGAs), ApplicationSpecific Integrated Circuits (ASICs), and other similar electronicdevices. Thus, any software-implemented method described herein may beemulated by a hardware-based VHDL program, which is then applied to aVHDL chip, such as a FPGA.

Having thus described embodiments of the invention of the presentapplication in detail and by reference to illustrative embodimentsthereof, it will be apparent that modifications and variations arepossible without departing from the scope of the invention defined inthe appended claims.

1-5. (canceled)
 6. A computer program product for retrieving a nestedresource of software modules, the computer program product comprising: acomputer readable storage medium having stored thereon: first programinstructions executable by a processor to cause the processor toidentify dependent software modules that are required by a softwaremodule; second program instructions executable by a processor to causethe processor to consolidate the software module with the dependentsoftware modules to generate an aggregated software module, wherein theaggregated software module is a nested resource of software modules;third program instructions executable by a processor to cause theprocessor to transmit, from a client-side module loader in the clientcomputer to a module server, a request for the aggregated softwaremodule, wherein the client-side module loader is incapable ofidentifying a name of received software modules from the module server;and fourth program instructions executable by a processor to cause theprocessor to receive, by the client-side module loader in the clientcomputer, a requested aggregated software module.
 7. The computerprogram product of claim 6, further comprising: fifth programinstructions executable by a processor to cause the processor topopulate a software framework with the requested aggregated softwaremodule.
 8. The computer program product of claim 6, further comprising:fifth program instructions executable by a processor to cause theprocessor to utilize, via the client-side module loader, asynchronousmodule definition (AMD) specification commands to define and consolidatethe software module with the dependent software modules to generate theaggregate software module, wherein the AMD specification commandscomprise a “define” command to identify the dependent software modulesthat are required by the software module, and wherein the AMDspecification commands further comprise a “require” command toconsolidate the software module with the dependent software modules togenerate the aggregated software module.
 9. The computer program productof claim 8, wherein the module server recognizes the aggregated softwaremodule using AMD specification commands without any plugins.
 10. Thecomputer program product of claim 6, further comprising: fifth programinstructions executable by a processor to cause the processor to, inresponse to the client-side module loader determining that a particulardependent software module from the dependent software modules has beenpreviously loaded onto the client computer, remove the particulardependent software module from the aggregated software module beforetransmitting the request for the aggregated software module to themodule server.
 11. A system comprising: a processor, a computer readablememory, and a computer readable storage medium; first programinstructions to identify dependent software modules that are required bya software module; second program instructions to consolidate thesoftware module with the dependent software modules to generate anaggregated software module, wherein the aggregated software module is anested resource of software modules; third program instructions totransmit, from a client-side module loader in the client computer to amodule server, a request for the aggregated software module, wherein theclient-side module loader is incapable of identifying a name of receivedsoftware modules from the module server; and fourth program instructionsto receive, by the client-side module loader in the client computer, arequested aggregated software module; and wherein the first, second,third, and fourth program instructions are stored on the computerreadable storage medium for execution by the processor via the computerreadable memory.
 12. The system of claim 11, further comprising: fifthprogram instructions to populate a software framework with the requestedaggregated software module; and wherein the fifth program instructionsare stored on the computer readable storage medium for execution by theprocessor via the computer readable memory.
 13. The system of claim 11,further comprising: fifth program instructions to utilize, via theclient-side module loader, asynchronous module definition (AMD)specification commands to define and consolidate the software modulewith the dependent software modules to generate the aggregate softwaremodule, wherein the AMD specification commands comprise a “define”command to identify the dependent software modules that are required bythe software module, and wherein the AMD specification commands furthercomprise a “require” command to consolidate the software module with thedependent software modules to generate the aggregated software module;and wherein the fifth program instructions are stored on the computerreadable storage medium for execution by the processor via the computerreadable memory.
 14. The system of claim 13, wherein the module serverrecognizes the aggregated software module using AMD specificationcommands without any plugins.
 15. The system of claim 11, furthercomprising: fifth program instructions to, in response to theclient-side module loader determining that a particular dependentsoftware module from the dependent software modules has been previouslyloaded onto the client computer, remove the particular dependentsoftware module from the aggregated software module before transmittingthe request for the aggregated software module to the module server; andwherein the fifth program instructions are stored on the computerreadable storage medium for execution by the processor via the computerreadable memory.